home *** CD-ROM | disk | FTP | other *** search
/ Super Audio / Super Audio.iso / replay / _armovie / documents / tocapture < prev    next >
Text File  |  1997-11-10  |  11KB  |  189 lines
  1.               Requirements for an Acorn Replay Capture program
  2.  
  3. Video Data
  4.  
  5. (1) The Acorn Replay compressors take (any) Acorn Replay files as their
  6. input data. There are 6 possible forms of (uncompressed) input data:
  7.  
  8. - 15 bit rgb pixels: each pixel is 5 bits of red, green and blue (red in
  9.   bits 0-4, green in 5-9, blue in 10-14, bit 15 zero). Pixels recorded in
  10.   successive half words. ARMovie file compression format 2, pixel depth 16.
  11.  
  12. - 15 bit YUV pixels: each pixel is 5 bits of Y (luminance), U and V
  13.   chrominance signals (Y in bits 0-4, U in 5-9, V in 10-14, bit 15 zero).
  14.   Pixels recorded in successive half words. ARMovie file compression format
  15.   2, pixel depth 16 with YUV in the pixel depth field.
  16.  
  17. - 20 bit YYUV pixel pairs: two pixels recorded with two 5 bit luminance
  18.   signals and one set of common U and V chrominance signals (Y1 in bits
  19.   0-4, Y2 in bits 5-9, U in bits 10-14, V in bits 15-19). Pixels recorded
  20.   in successive 20 bit values: 160 bits (5 32 bit words) represents 16
  21.   pixels and is a basic recording unit. ARMovie file compression format 3,
  22.   pixel depth 16 with YUV in the pixel depth field.
  23.  
  24. - 8 bit grayscale: one pixel per byte. No compressor yet exists for this
  25.   data, but files can be played. ARMovie file compression format 4, pixel
  26.   depth 8.
  27.  
  28. - 30 bit YYYYUV pixel quads: four pixels in a square recorded with
  29.   individual luminance signals and one set of common U and V chrominance
  30.   signals, the whole thing held as one word (Y1 in bits 0-4, Y2 in bits
  31.   5-9, Y3 (second row) in bits 10-14, Y4 in bits 15-19, U in bits 20-24,
  32.   V in bits 25-39, bits 30 and 31 zero). ARMovie file compression format 5,
  33.   pixel depth 16 with YUV in the pixel depth field.
  34.  
  35. - 90 bit YYYYYYYYYYYYYYYYUV pixel sixteens: 16 pixels in a square recorded
  36.   with individual luminance signals and one set of common U and V
  37.   chrominance signals, the whole thing held as three words (Y1 to Y6 in
  38.   bits 0-29 of word 0, Y7 to Y12 in bits 0-29 of word 1, Y13 to Y16 in
  39.   bits 0-19, U in bits 20-24, V in bits 25-29 of word 2, all bits 30 and
  40.   31 zero). ARMovie file compression format 6, pixel depth 16 with YUV in
  41.   the pixel depth field.
  42.  
  43. If possible, avoid the pedestals usually found on systems - occupy the full
  44. 0-31 range of the components (or 0-255 for grayscale). Gamma correction is
  45. assumed to have been done (so that equal increments in the input range are
  46. approximately equal perceptual increments). Frame size is recorded in the
  47. ARMovie file header: although ARMovie files can have arbitary numbers of
  48. pixels in a frame, the Acorn Replay Moving Line compressor expects the
  49. frame to be a multiple of 8 pixels horizontally. 160x128 or 160x120 are
  50. typical sizes: these play back at 1/4 screen VGA. The space used for the
  51. formats is:
  52.  
  53. format  bits used  Bytes used per
  54.         per pixel  frame at 160x128    pixel multiples x    y
  55.   2         16         40960               x1               y1
  56.   3         10         25600               x2               y1
  57.   4          8         20480               x4               y1
  58.   5          8         20480               x2               y2
  59.   6          6         15360               x4               y4
  60.  
  61. Acorn can supply sample ARMovie files in all formats if required. Acorn can
  62. also supply an !ARMovie directory containing decompressors (with source) for
  63. types 2, 3, 4, 5 and 6.
  64.  
  65. (2) All frames should be image processed the same way. Dithering of some
  66. form is recommended when converting from 8 bits per sample to 5 bits per
  67. sample, Floyd Steinberg dithering (or some other scheme having low error
  68. propagation values) is preferred, but dithering to the right pixel is
  69. acceptable - it results in lower compression factors, but not as bad as no
  70. dithering - provided the input data can stand the slight smearing that
  71. results. With any of the YUV formats, it is possible to dither only the Y
  72. signals. Sharpening is not recommended since it results in lower comression
  73. factors. Scaling by linear interpolation (equal area weighting or other
  74. filtering schemes) is recommended to produce images of the required size.
  75. Point sampling is permitted but *not* recommended. Frame sizes should be a
  76. multiple of 8 pixels horizontally.
  77.  
  78. (3) The ARMovie file is usually called "Capture". It is recommended that it
  79. is a multiple of 50 (60) frames in length (or a multiple of 25 frames in
  80. length if recorded at 12.5fps). If you wish to allow for immediate play back
  81. of the captured data, it may be necessary to restrict the chunk size to less
  82. than 1MByte (i.e. 1 second chunks instead of the more usual two seconds): the
  83. !ARMovie Player provided by Acorn uses double buffered chunk IO and thus
  84. loads two chunks at once: a 25 fps 160x128 capture in format 2 with 2 second
  85. long chunks is 2 MByte per chunk and can only be played on machines with
  86. more than 4MBytes free.
  87.  
  88. (4) For mastering a movie at both 25fps and 12.5fps (30fps and 15fps if you
  89. happen to be a 60Hz provider), all frames must be recorded. The Acorn Replay
  90. compression software will make a 25fps movie using all frames and a 12.5fps
  91. movie using only the even numbered frames.
  92.  
  93. (5) For mastering a movie at only 12.5fps (15fps) it is possible to record
  94. only the even (or odd - your choice) frames. It need only be a multiple of 25
  95. (30) frames in length.
  96.  
  97. (6) The !ARMovie Player program can play format 2, 3, 4, 5 and 6 directly,
  98. providing the source media is fast enough. This gives direct evidence of sound
  99. sync etc. If the source isn't fast enough, then use -speed to slow the play
  100. rate down (e.g. -speed 0.5).
  101.  
  102. (7) Writing the ARMovie file. Note that the last chunk in the movie need not
  103. have the same number of frames in it as all the other chunks: just write the
  104. catalogue entry correctly (the sound can be cut immediately by an appropriately
  105. short catalogue entry). The various pointers in the header of the ARMovie file
  106. all need to be filled in properly or it doesn't work! Two fields in particular
  107. are the number of chunks and the catalogue of chunk offsets.
  108.  
  109. (a) If you know the length (say, in seconds) in advance of making the
  110. recording, then the number of chunks field can be written directly the
  111. header is written (note that its the number of chunks -1: a 2 second long
  112. movie with 2 second chunks has 0 s the number of chunks). If you are not
  113. recording the sound, the number of bytes in a chunk will be constant and
  114. the catalogue can also be written directly, with each catalogue entry
  115. calculated to contain what will be written. Then write the data. If the
  116. sound is being recorded, the number of samples per sound grab may well
  117. vary (especially if approximating an irrational frequency like 1/72uS):
  118. the catalogue needs to be written after the chunks have been written, so
  119. make enough space (e.g. in the wimpslot) to keep the entire catalogue in
  120. RAM; write all the chunks, then write the catalogue after the chunks, then
  121. go back to the start of the file and ammend the catalogue pointer.
  122.  
  123. (b) if you don't know the length, then the strategy is similar to (a)
  124. above: write the header, write all the chunks keeping the data which will
  125. be used to construct the catalogue in RAM, finish recording by writing
  126. the final chunk, write the catalogue, then go back and ammend the header
  127. to have the correct number of chunks and correct catalogue pointer.
  128.  
  129. Sound Data
  130.  
  131. (1) It is required that the sound sampler's notion of time and the video
  132. sequence's notion of time agree: otherwise the sound will start in sync with
  133. the video and drift out as the clip is played. This can be achieved either
  134. by extreme accuracy of player and sampler (both to within 1/10 second after
  135. 1000 seconds, say) or by GENLOCKing the player and sampler togther. Since
  136. most professional video equipment has GENLOCK input capability, Acorn
  137. recommend that the sampler's clock is divided down to produce a VSync-like
  138. signal to which the video source is GENLOCKed.
  139.  
  140. (2) Sound capture must be started in frame sync with the video sequence. The
  141. sound sample must be continuous and extend to the end of the video sequence
  142. (preferably just beyond the end!). There should be no AGC or other systems
  143. used to unnaturally alter the sound level.
  144.  
  145. (3) Sound data should be oversampled at at least twice the desired replay
  146. rate: for example, if the replay rate is to be 10,000Hz, then the sample
  147. should be made at at least 20,000Hz, with the data resampled to 10,000Hz.
  148. Alternatively, you can capture at the desired replay rate using one of the
  149. modern over-sampling-with-dsp-decimation devices which does it all for you.
  150.  
  151. (4) Sample rate (and thus replay rate) must be specified precisely - don't
  152. say 10,000Hz when you mean 10,000.25Hz!!!! Precise numbers of uS can also be
  153. represented: 72 means 72 uS rather than 72Hz (true up to 255 uS).
  154.  
  155. (5) The replayed data uses VIDC's exponential format for greater dynamic
  156. range. Input data should be 16 bit linear or 8 bit exponential (bytes). 16
  157. bit linear data can be converted to 8 bit exponential format with the
  158. program "Convert" or to ADPCM 4 bit format with the program "s16toa" (see
  159. 'ToRunDiffer'). 8 bit linear data should be left alone: Replay will convert
  160. it to exponential format as the data is replayed - in order for this to
  161. happen correctly, the movie header MUST contain the word "linear" in the
  162. number of bits entry for sound. 
  163.  
  164. (6) Although the sound data should be held in the ARMovie "Capture" file, it
  165. may be hard to do this if sound and video are being recorded seperately. So
  166. an 8 bit sound sample can also be held as a different ARMovie file, or as one
  167. RISC OS file "Sound" at the top level of the hierarchy of files. 16 bit files
  168. are called "Samples". ADPCM files are called "ADPCM". These files may also
  169. exist if sound is derived from the captured sound before being made into the
  170. final movie.
  171.  
  172. Other Data
  173.  
  174. (1) A header containing all the textual information for the ARMovie (AE7)
  175. file produced by the compressors must be supplied and called "1Header" or
  176. "2Header". This file is especially important if the ARMovie "Capture" file
  177. contains no sound, since it is the reference for it. The chunk size in these
  178. header files should be 2 seconds.
  179.  
  180. (2) A default sprite called "Sprite" must be supplied. This should contain
  181. an image the same size as the movie in mode 13 pixels (the sprite can be
  182. mode 15 or mode 28 if required).
  183.  
  184. (3) Acorn have converters for old captured data. These programs are
  185. basically modified compressors which work on old capture trees, writing out
  186. Images which can then be Joined by old Joiners to make type 2 or type 3
  187. format ARMovie files. Please contact Acorn if you need these, however we
  188. don't consider them 'user friendly'!
  189.